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SUBSCRIBER MANAGEMENT SYSTEM AND METHOD 
FIELD OF THE INVENTION 

The present invention relates generally to the field of 
computer networks and applications and more specifically, to computer 
5 networks for operating customer-oriented systems. More specifically, the 
present invention relates to a computer network and a series of 
applications running thereon for interconnecting and operating multiple 
cable business units. 

BACKGROUND OF THE INVENTION 

10 Cable television has become immensely popular over the 

last several decades. Due to the rapid growth and expansion of this 
industry, many different entities have participated in establishing local 
cable systems to meet the growing demand. As such, most local cable 
systems have different requirements, different equipment, different 

15 customer tastes, etc. Almost no two local cable systems are alike and the 
differences which have resulted from the rapid growth of the cable 
industry have made centralized control over the operations of the local 
operators a difficult and burdensome task. 

One particular problem involves the definition of products 

20 and services. For example, if a multiple system operator (MSO) owning 
four local cable systems in four different regions of the country wishes to 
set pricing information for a particular product, it would have to contact 
each of the four local cable systems, establish the pricing information, and 
supervise the local cable systems to ensure that the pricing information 

25 for that particular product was properly applied to the customers. This is 
just one example of many in which monitoring and controlling operations 
of the MSO's perspective is burdensome under the present systems. 

These problems are exacerbated in more complex MSO 
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structures in which a main MSO office may oversee a plurality of regional 
offices which may oversee a plurality of divisions which may oversee a 
plurality of state offices which may oversee a plurality of cable providers 
and/or other MSO's. The iterations and complexities are almost endless 

5 in the present cable industry. 

Bill production can be another difficult task when business 
hierarchies become large and complex. The reason for this is twofold. 
First, the sheer volume of data to be processed can be problematical. 
Secondly, the complexities of the interrelationships between customers, 

10 accounts and services can lead to confusion, increased processing time 
and the potential for errors. With each of the local systems and MSOs 
establishing individual pricing for products, services, and packages, the 
process for generating bills for each individual subscriber can become 
complex, time consuming and error prone. Often, the time required to 

15 process a billing cycle can be excessive. This can cause numerous 
negative effects on the operation of the business including delay in 
receiving revenue, confused or hostile customers and late bills. Moreover, 
since many architectures employ the same servers for database requests 
originating from both OLTP and batch processes, an extended billing 

20 batch can have a long term negative impact on system performance from 
an OLTP standpoint. 

Another drawback of currently existing systems with 
respect to the bills that they generate is the treatment of data in a discrete 
fashion. For example, account data, service location data and subscriber 

25 data are not cohesively related. Various pieces of information, although 
logically related, are treated as separate abstractions without any 
relationship between such data represented in the system. Thus, in the 
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case of an individual (e.g. a landlord with multiple rental units) having 
multiple accounts in different physical locations, multiple bills -one for 
each rental unit -would generally have to be generated for that single 
individual. This has obvious drawbacks including increased overall bill 
5 processing time, increased postage costs, inconvenience to the subscriber 
and resource (e.g. paper) waste. 

Yet another problem existing in current billing applications 
relates to error handling. Often, during batch processing of bills, the 
processing of a particular bill will result in an error. Typically, current 
1 0 systems will respond to this event by discarding the batch, manually 
processing the bill causing the error or even removing that bill from the 
batch and then restarting the batch from the beginning. This scenario will 
often take place even if the batch has been nearly completed at the time 
that the error occurs. As is apparent to one of skill in the art, such 

15 treatment is undesirable in that system resources will be strained to 
complete the same batch portions multiple times. 

A third area in which current systems for handling the 
operation of large business entities are deficient involves the way in 
which data is accessed in performing the above and other tasks. The 

20 telecommunications industry and particularly the cable television industry 
have a particularly great need for storage and manipulation of large 
amounts of data. Cable system operators typically maintain large 
databases containing a variety of subscriber, product and billing 
information. Typical classes of information managed by cable companies 

25 include subscriber accounts, available products and their pricing structure, 
physical assets and their functionality and marketing data. It is often 
desirable to distribute this information across a network of databases 
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whether or not they are located at the same physical location. 

The processing requirements for cable based systems can be 
staggering. For example, it may be necessary to provide 24 hour a day, 7 
day a week service for a subscriber base of millions or tens of millions of 

5 subscribers. In addition, such a system may be called upon to execute 
hundreds or thousands of transactions per second (TPS). In addition, 
such systems may be required to support thousands of interactive users 
operating client terminals (e.g. Customer Service Representatives (CSRs)) 
many of which may be concurrent users. It is further anticipated that the 

10 average customer record may soon be on the order of 15 kilobytes 

requiring a total database capacity of about 225 Gigabytes (assuming 15 
million subscribers). 

A typical distributed database system that may be employed 
by a system operator includes a plurality of transaction generators or 

1 5 terminals which may be operated by CSRs to acquire access to data 
contained within the system. Each of the transaction generators 
communicates either directly or through a communications controller with 
a particular associated server or servers. Communication techniques and 
protocols which are known in the art are employed to allow the 

20 transaction generators to communicate with the servers. For example, 
Ethernet™ may be used when both client and server are PC-based 
processors. 

In current systems, difficulty arises when access to data 
residing at differing locations is required. This places a burden on the 
25 CSR (or a transaction generator in general) because it may impose 
additional processing requirements to keep track of what data is 
accessible to a particular CSR and which is not. Additionally, if certain 
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data is needed, but not accessible to a particular CSR, it may be necessary 
to determine where the data is located and which CSR may have access to 
that data. 

An example of such a system exhibiting the drawbacks 
5 described above may include four data processing centers to support a 
national cable system operator. Each of four geographical regions in the 
United States (e.g. Northeast, Southeast, Midwest and West) may be 
supported by one of the four data processing centers. In such a case, all 
records for customers of the system operator who reside in Pennsylvania 

10 would be stored at the Northeast data center in its associated database. In 
the event that a particular Pennsylvania subscriber is at home and desires 
to receive information about his or her account the process is relatively 
simple. The subscriber may call in to a CSR operating a transaction 
generator connected with the Northeast database. The CSR, using the 

1 5 transaction processor, can simply generate a request for information 
regarding that subscriber. Alternatively, the subscriber may call in to an 
Automatic Response Unit (ARU) having an Automatic Number Indicator 
(ANI) interface and a similar request for information would be generated 
automatically. 

20 The problem, however, arises when the same Pennsylvania 

subscriber also maintains a business account across the border in Ohio. 
Even though both accounts are serviced by the same system operator, a 
single call by the Pennsylvania/Ohio subscriber will not permit him or her 
to receive information about both accounts. This is because the Ohio 

25 account information will be located at and serviced by the Midwest data 
center. Since the transaction processor at the Northeast data center has no 
connection to the Midwest data base and since the transaction processor 
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at the Midwest data center has no connection to the Northeast data base, 
the subscriber is forced to first call the Northeast data center for 
information about the residential account and then the Midwest data 
center for information about the business account. In addition, this 
5 subscriber is likely to receive two separate billing statements, one from 
each data center. 

An additional drawback with this hypothetical system 
becomes evident when it is necessary to obtain system wide data. For 
example, a system operator may desire to retrieve data based upon 

10 subscriber demographics. Suppose, for example, the marketing 
department wishes to generate an alphabetical list of the names and 
addresses of all subscribers, system wide, who are over the age of 30 and 
subscribe to ESPN. It is necessary, using the above described system, to 
separately access data within each of the four regions. Once data from 

15 each of the regions is gathered, it is further necessary to merge the data 
originating from each of the regions to generate one comprehensive list. 
The problems which are illustrated in this example are exacerbated when 
more than four data processing centers are used. 

The method of distribution of customer records in the above 

20 example is known in the art as horizontal data distribution. In the above 
case, each of the customer records is completely contained on one 
physical server while the whole of its associated database and the 
enterprise domain of all customers is spread across all servers. 

A fourth area in which customer oriented data processing 

25 systems have been less than satisfactory is in the area of the interface 
which is used by Customer Service Representatives (CSRs) to interact 
with the system. Interfaces to date have been cumbersome and often 
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require a CSR to scroll and page through large amounts of information 
before arriving at the desired information or data entiy field. As can be 
imagined, this can significantly increase the time period during which a 
customer must be on the phone with a CSR in order to complete a 
5 transaction or receive requested information. As a result of these less 
than satisfactory user interfaces, customers can become frustrated with 
the delays they may encounter when calling CSRs. Further, longer call 
times translate into less throughput per available CSR. Thus, customers 
may wind up waiting in order to even begin talking to a CSR. 
10 Alternatively, it may become necessary to hire additional CSRs in order 
to alleviate delays which are unacceptable to customers. 
SUMMARY OF THE INVENTION 

Thus, a need has arisen for a system which allows 
centralized and hierarchical control over the operations of local cable 
1 5 systems. It is an object of the present invention to overcome these and 
other disadvantages of the present systems. 

It is an object of the present invention to provide centralized 
product definition such that entities at each level in the hierarchical chain 
may establish parameters about the product which must be followed by 
20 any entities lower on the hierarchical chain. 

It is another object of the present invention to provide a 
system which enables any entity in the system access to information about 
any customer or account in the system. 

It is still another object of the present invention to provide a 
25 system which allows customer service representatives from any entity of 
the system access to the information about customers and accounts 
located anywhere within the system. 
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It is a further object of the present invention to provide a 
batch processing system having minimal impact on the performance of 
OLTP transactions. 

It is a still further object of the present invention to provide 
5 a billing system which allows for centralized control over billing 
operations. 

It is yet another object of the present invention to provide a 
billing system which logically reflects relationships among the data to be 
processed. 

10 It is a yet further object of the present invention to provide a 

system which can effectively and rapidly process large billing batches. 

It is a still further object of the present invention to provide 
a system wherein a batch need not be restarted from the beginning in the 
event a single batch component fails. 
15 It is a further object of the current invention to provide a 

distributed database system capable of high speed transaction processing. 

It is a yet further object of the invention to allow database 
access while eliminating the need for time consuming processes normally 
associated with such access. 
20 It is a still further object of the invention to provide server 

selection based upon a rules base allowing fast and efficient access to 
distributed information. 

It is an even further object of the present invention to 
provide a distributed database system in which particular servers may be 
25 designated for the servicing of requests based upon the nature or type of 
request to be serviced. 

It is a yet further object of the present invention to provide a 



7/20/06, EAST Version: 2.0.3-0 



WO 97/24691 



PCT/US96/20125 



9 

system having an easy to use and logical interface so that customer 
service representatives may easily and rapidly interface with and use the 
system. 

Accordingly, the present invention comprises a system and 
5 method for allowing various users to coordinate, track and manage 
business tasks necessary for delivering cable television products and 
services. Although the present invention is described in the context of a 
cable television business environment, its teachings may be applied on a 
broader scale to include any business operation which requires such 
10 coordination, tracking and managing of its business tasks. 

The system of the present invention allows users to quickly 
access customer and field personnel information, market expanding and 
diversified services, make informed business decisions and quickly access 
a variety of corporate and lower level information. The system further 
15 enables efficient access to data located in a centralized database including 
dispatching information, addressability information, billing information, 
lockbox information and credit card data. The architecture of the system 
allows for communication and coherency between the corporate business 
unit, regional service centers, individual cable systems, and other business 
20 units. Remote locations may be added to provide expanded service such 
as for automated call routing in the case of overload at a particular site. 

The system is defined by a plurality of node office systems 
which are connected to an operational management system over a wide 
area network, for example. Each node office system has a plurality of 
25 customers, service locations and accounts associated therewith. Each 
node office system comprises a cable television product delivery device 
which provides a cable television product to a service location associated 
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with that node office system. Further, each node office system comprises 
at least one node customer service processor which accesses the memory 
and presents information contained in any customer record, any service 
location record, and any account record stored in the memory. The node 
5 customer service processor and the main customer service processor 
enable a user to request that a new customer record be created for 
customers of any of the plurality of node office systems, service location 
records for service locations connected to any of the plurality of node 
office systems, and account records for accounts associated with any of 

10 the plurality of node office systems. 

According to another aspect of the present invention, the 
system operates so as to associate related data in a unique manner. 
Specifically, a plurality of customers are associated with one or more 
accounts and with one or more service locations, and memory is allocated 

15 for storing customer records, account records, and service location 

records. The memory associates each customer record with at least one 
account record and at least one service location record, each account 
record with at least one customer record and at least one service location 
record, and each service location record with at least one customer record 

20 and at least one account record. The system also comprises at least one 
customer service processor which accesses the memory for information 
contained in any customer record, any service location record, and any 
account record stored in the memory means. 

The customer service processor includes an input device 

25 which receives customer service requests, a memory access device which 
retrieves at least one customer record, at least one account record, and at 
least one service location record in response to the customer service 
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request, and a display. The customer service processor controls the 
display to present a graphical user interface comprising a banner window, 
an account window, and a service location window. The banner window 
comprises fields for customer related information. The account window 
5 comprises fields for account related information. The service location 
window comprises fields for service location related information. The 
novel graphical user interface allows a customer service representative to 
alter customer, service location and account records stored in the memory. 

10 The system of the present invention further includes a 

unique subsystem and method for data access and storage. At least one 
Data Directory Server (DDS) is included and is located between one or 
more transaction generators and one or more data servers. The DDS 
efficiently routes transactions and provides data location fiinctions. The 

15 DDS provides high data availability, high on-line transaction rates, batch 
capabilities, scalability and maintainability. In particular, based upon 
internal rules and the particular transaction type, the DDS routes 
transactions to the appropriate servers). Transactions are classified 
according to where they may be executed. Specifically, transactions may 

20 be classified as SPECIFIC, ANY or ALL. A SPECIFIC transaction must 
be processed at one or more specific servers irrespective of the 
accompanying arguments. An ANY transaction may be processed at any 
of the servers and selection is made psuedorandomly. An ALL transaction 
requires processing by each of the data servers. 

25 Other aspects, features, and advantages of the present 

invention will become apparent to one of ordinary skill in the art upon 
consideration of this specification and the accompanying figures. 
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DEFINITIONS 

In order to aid in the explanation of the objects and 
advantages of the present invention, the following definitions are 
provided. 

5 A cable provider is generally any entity which has a 

franchise or other legal right to allow that entity to provide cable 
television programming. 

A customer is generally the person or legal entity (an 
individual or a company) that is financially responsible for programming 
10 and other services purchased from a cable provider. For example, the 
customer may be Joe Smith or ABC, Inc. 

A service location is generally the physical site (a house, 
apartment, or business, e.g.) at which a cable provider provides, or could 
provide, programming and other services. For example, the service 
15 location may be 123 Walnut Street, Cooperstown, New York. 

An account is generally an informational link between a 
customer and a service location. 

A product is generally a good or service provided by the 
cable provider to the customer. For example, the product may be 
20 anything from Home Box Office to installation. 

A product parameter is generally any parameter which 
defines the product. Product parameters may include product name, 
product availability, or product pricing, to list just a few. 
BRIEF DESCRIPTION OF THE DRAWINGS 
25 Fig. 1 depicts an overall system architecture according to 

one embodiment of the present invention. 

Fig. IB depicts a schematic of the hierarchical structure of 
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Fig. 1 according to one embodiment of the present invention. 

Fig. 2 depicts a divisional office system and a regional call 
center according to one embodiment of the present invention. 

Fig. 3 depicts a node office system according to one 
5 embodiment of the present invention. 

Fig. 4 depicts an operational management system according 
to one embodiment of the present invention. 

Fig. 4A is a flowchart illustrating the bill production process 
according to one embodiment of the present invention. 
1 0 Fig. 5 depicts an operational management system according 

to one embodiment of the overall system architecture of Fig. 1. 

Fig. 6 depicts a flow diagram of a user interface system 
according to one embodiment of the present invention. 

Fig. 7 depicts a graphical user interface according to one 
15 embodiment of the present invention. 

Fig. 8 depicts a customer window according to one 
embodiment of the present invention. 

Fig. 9 depicts a customer window according to another 
embodiment of the present invention. 
20 Fig. 10 depicts a service location window according to one 

embodiment of the present invention. 

Fig. 1 1 depicts a service location window according to 
another embodiment of the present invention. 

Fig. 12 depicts a bill window according to one embodiment 
25 of the present invention. 

Fig. 13 depicts a bill window according to another 
embodiment of the present invention. 
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Fig. 14 depicts an account window according to one 
embodiment of the present invention. 

Fig. IS depicts an account window according to another 
embodiment of the present invention. 
5 Fig. 16 depicts an account window according to yet another 

embodiment of the present invention. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

An overall system architecture according to one 
embodiment of the present invention is depicted in Fig. 1. System 10 in 

10 Fig. 1 comprises a operational management system 12, hierarchical 
systems 30, and support systems 32. Hierarchical systems 30 may 
comprise a plurality of divisional office systems 16, a plurality of state 
office systems 18, a plurality of franchise systems 20, and a plurality of 
node office systems 28, distributed over a wide area network (WAN) 100. 

15 Hierarchical systems 30 may also comprise one or more regional call 
centers 14 distributed on WAN 100. 

In a preferred embodiment, each franchise system 20 may 
control the operations of a single cable provider or a plurality of cable 
providers. If a plurality of cable providers are controlled, then each 

20 franchise system 20, in this preferred embodiment may have one or more 
node office systems 28 associated therewith. 

Support systems 32 may comprise a bill printing system 22, 
a bill payment system 24, and an accounting system 26 distributed on 
WAN 100. System 10 may also comprise additional systems distributed 

25 on WAN 100. 

System 10 may comprise an architecture in which five 
hierarchical levels exist. This is illustrated in Figure IB. In this 
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embodiment, for example, the hierarchical order may be operational 
management system 12, divisional office systems 16, state office systems 
18, franchise systems 20, and node office systems 28. It is also possible 
for others numbers of hierarchical levels to exist. 
5 In a preferred embodiment, operational management system 

12 has hierarchical control over each system of hierarchical system 30, 
each system of support system 32, and any other system distributed on 
WAN 100. As such, centralized control of every system on the network 
may be achieved. Within hierarchical control system 30, control may be 
10 exercised according to hierarchy. 

Fig. IB depicts a schematic of the hierarchical control 
provided according to one embodiment of the present invention. OMS 12 
controls a plurality of divisional office systems 16. For example, m 
divisional office systems 16 may be provided, where m may equal from 1 
15 to 100 or more. Each divisional office system 16 controls certain 
operations of a plurality of state office systems 18 to which it has been 
assigned. For example, divisional office system number 1 may control 
state office systems 1,1 to l.p where p may equal an integer from 1 to 50 
for example. Divisional office system number 2, on the other hand, may 
20 directly control one or more franchise systems 20. 

Each state office system 18 may control certain operations 
of a plurality of franchise systems 20 or franchise/node systems 20/28 to 
which it has been assigned. A franchise/node system 20/28 may be a 
franchise having only one node and thus operating as a node system 28 as 
25 described herein. For example, state office system l,p controls franchise 
systems l,p, 1 to l,p,s where s may be an integer from 1 to 100 or more. 

Each franchise system 20 controls certain operations of at 
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least one node office system 28 assigned to the franchise system. For 
example, franchise system m, l,x may control node systems m, l,x, 1 to 
m,l,x,c where c is an integer from 1 to 100 or more. 

In a preferred embodiment, each node office system 28 is 
5 assigned to one and only one franchise system 20, each franchise system 
20 is assigned to one and only one state office system 1 8 or one and only 
one divisional office system 16 or directly to OMS 12. Each state office 
system 18 is assigned to one and only one divisional office system 16 or 
directly to OMS 12. Each divisional office system 16 is under the direct 

10 control of operational management system 12. 

Although divisional office systems 16, and state office 
systems 18 may have different functions as described below, their system 
architecture may be basically similar. Fig. 2 depicts a system architecture 
for a divisional office system 16 and a regional call center 14. Divisional 

15 office system 16 may comprise a main divisional processor 40 connected 
to WAN 100, a plurality of customer service processors 42 in 
communication with main divisional processor 40, and an automatic 
response unit (ARU) 39 connected to main divisional processor 40. Main 
divisional processor 40 comprises a product/rating subprocessor 4 1 . ARU 

20 39 may be operatively connected to customer telephone equipment 
through a telephone line or two way cable, for example. ARU 39 then 
may operate to indicate to main divisional processor 40 certain 
information about a customer calling with a request. This information 
may then be passed through to one of the customer service processors 42 

25 assigned to handle the customer's requests or may be handled 

automatically. The operations of ARU 39 will be described in greater 
detail below. 
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The architecture for a state office system 18 may be similar 
to divisional office system 16. In a preferred embodiment, state office 
system 1 8 may comprise a main state processor having a product/rating 
subprocessor connected to WAN 100, an ARU connected to the main 
5 processor and to a phone line or two way cable which is connected to 
customer telephone equipment, and a plurality of customer service 
processors in communication therewith. 

Regional call center 14 may comprise a regional call center 
processor 43, an automatic response unit 47 connected to the regional call 
1 0 center processor 43 , and a plurality of customer service processors 4 5 
connected to regional call center processor 43. Regional call center 14 
may be associated with one or more node office systems 28 and/or one or 
more franchises 20. Preferably, regional call centers 14 operate to handle 
overflow requests at one or more node office system 28 or one or more 
1 5 franchise systems 20 with which they are associated. Regional call 
centers 14 may also directly service customer requests or inquiries. 

Fig. 3 depicts one embodiment of a node office system 28. 
Node office system 28 comprises a node processor 50 connected to WAN 
100. Node processor 50 may comprise one or more sub processors. For 
20 example, node processor 50 may comprise a technician control 

subprocessor 52, a product/rating subprocessor 53, and an administration 
subprocessor 54. Technician control subsystem 52 may be in 
communication with one or more technicians who may be called upon to 
act in response to service requests at one of the service locations assigned 
15 to node office system 28. Administration subsystem 54 may control 
internal operations of the node, for example. Product/rating subprocessor 
53 establishes product information and pricing for products available at 
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the node as described in detail below. Node processor 50 may also have 
connected thereto a plurality of customer service processors 56. 

Node processor 50 may also be connected to a head end 
unit 58 and its associated head end controller 62. Head end controller 62 

5 may also be connected directly to WAN 100. Head end 58 may also be 
connected to one or more satellite receivers 60 according to known 
techniques in the art. Head end 58 may further be connected via 
connection 66 to a converter box connected to a television 74 or directly 
to television 74 at one or more service locations 64. Connection 66 

10 between head end 58 may be by coaxial cable, fiber optic cable, or 
telephone lines, for example. Other methods of connections including 
over-air signal transmission such as by microwave, for example, may also 
be used. 

Node processor 50 may also be connected to an automatic 
15 response unit (ARU) 70. ARU 70 is connected to incoming telephone 
lines 68 and operates to identify incoming callers to more quickly direct 
their calls. Telephones 72 at service locations 64 may be connected to 
telephone lines 68 and thus to ARU 70. Details of ARU operations are 
provided in greater specificity below. 
20 Franchise system 20 may either resemble divisional office 

system 16 or node office system 28. Franchise system 20 may be 
associated with one or many nodes. If only one node is present, then 
franchise system 20 is a node system and thus may be similar to node 
office system 28 depicted in Fig. 3. If more than one node office system 
25 28 is associated with a particular franchise system 20, then franchise 
system 20 may resemble divisional office system 16. 

Fig. 4 illustrates an embodiment of the operational 
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management system (OMS) 12 of the present invention. OMS 12 
generally includes operational processing system (OPS) 80, database 
access systems (DAS) 104, and customer service processors 102. OPS 80 
comprises multiple processing components 82-99 which are responsible 
5 for various functions of OMS 12. In a preferred embodiment, the 
processing components comprise a product/rating component 82, a 
dispatch component 84, an external interface component 86, a bill 
production component 88, an addressability component 90, a customer 
support component 92, an internal interface component 94, a reporting 

10 component 96, a global component 97, a telephone component 98, and a 
miscellaneous component 99. The above listed components are merely 
exemplary. For example, multiple DAS's 104 may be employed for 
redundancy as discussed in further detail below (for example, two are 
shown in Fig. 4). Additionally, OPS 80 may be distributed physically and 

15 /or logically so that each of the processing components 82-99 may reside 
on a separate OPS or various individual processing components may be 
grouped together on associated OPSs. 

As discussed above, each of the processing components 
may perform a variety of functions. Product/rating component 82 may be 

20 responsible for defining new products, redefining existing products, pay- 
per-view management, packages, promotions, installations and repair 
service definition, merchandise, product restrictions/blackouts, and rating 
maintenance, for example. The functions of product/rating component 82 
are described in detail below. 

25 The dispatch component 84 may be responsible for work 

order scheduling, technician quota points, work order routing, dispatch- 
GIS, technician maintenance, technician user interfaces, technician 
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devices, technician communication systems, equipment inventory, outage 
detection, global positioning systems, map images, digitized intelligent 
plants, and status monitoring. Other functions may also be performed by 
dispatch component 84. Generally, though, dispatch component 84 
5 processes information and requests regarding dispatch of service 
technicians to a customer site for repair, installation or other services. 

The external interface component 86 may be responsible for 
collections processes, subscriber payment maintenance such as credit card 
interfaces, lockbox interfaces, electronic funds transfer, drop box, 
10 cashiers, check-in process, and collection agencies, bill rendering, refund 
check rendering, and product usage payments, for example. External 
interface component 86 is the main component for interacting with 
support systems 32 and may function to communicate with other external 
processors as well. 

1 5 The bill production component 88 is preferably the main 

component for interfacing with outsourcing of bill generation. Bill 
product component 88 may be responsible for billing cycle maintenance, 
bill production, reminder notices/bill messaging, refunds processing, 
account aging, internal collections, write-off processing, subscriber 

20 notifications, marketing inserts, bill reprints, adjustments and credits, bill 
formatting, cash processing-payment, and bill archiving, for example. 

Bill production component 88 completes a bill batch 
according to three distinct subprocesses. Figure 4A is a flowchart 
generally describing the broad steps in bill production according to the 

25 present invention. The first subprocess is termed Bill Production Initiator 
(BPI). The BPI serves the general function of waking up periodically and 
initiating a billing cycle. The BPI selects the billing work within the OMS 
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12 that needs to be processed for the specified billing cycle. The second 
subprocess in completing bill production is the Bill Production Manager 
(BPM). Multiple BPMs may be operable at any one time. Each BPM 
preferably corresponds to a particular billing run for a particular business 
5 unit. For example, a BPM may be created for a billing run on the 15th of 
the month (billing cycle) for one particular node office (cable operator). 
Each BPM processes the billing work specified by the BPI in order to 
divide the work up into manageable units. Work is further divided by the 
BPM such that the most efficient overall processing takes place. Finally, 

10 the last major process in bill production as performed by billing 

component 88 is the Bill Production Worker (BPW). There are preferably 
multiple BPW processes running at a single time such mat each of the 
work groupings specified by the BPW may be processed by a BPW 
process. Further, multiple BPW processes allow for parallel processing of 

15 the bill production workload. The ultimate result of the BPWs (and the 
billing component 88 in general) is the generation of individual bills for 
customers. 

Upon completion of the BPW processes, various post 
production activities may occur. These activities may occur as part of the 

20 BPW process itself, requiring completion prior to BPW processing being 
considered completed. Alternatively, the post production activities may be 
separately processed following BPW processing but prior to actual bill 
rendering. In a preferred embodiment, the post production activities occur 
automatically as part of the bill production processing, however, post 

25 production activities may alternately be manually instituted upon certain 
events such as the completion of a BPW process. 

Post production activities may include, for example, storing 
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a copy of a bill image as generated by the BPW in the database for later 
access by a CSR on-screen in case a customer wishes to discuss an old or 
newly generated bill. Thus an archive database of customer bills is 
maintained within the system for some period of time so that images may 
5 be called up wherein the images will match the hard copies generated and 
mailed by the bill renderer. Another post production activity may be 
further steps in preparing the bill run for transmission to a bill renderer. 
For example, a header file may be created indicating such things as the 
number of bills following the header for the particular run, special fonts 

10 that will need to be accessed during printing of the subsequent bills, 

inserts that need to be included during preparation of the subsequent bills 
or special images that will need to be accessed during the printing of the 
subsequent bills. 

It is important to realize that bill production component 88 

1 5 must necessarily interface with other components of operational 

management system 12 in performing the bill generation process. For 
example, bill production component 88 must interface with addressability 
component 90, for example when bill production component 88 
determines that an account is past due during the aging process. In this 

20 case bill production component 88 causes addressability component 90 to 
place, for example, a pay-per-view inhibit flag on the subscriber's 
account and converter box. Similarly, and as is apparent to one of skill in 
the art, bill production component 88 interfaces with bill rendering system 
290 such that bill production component 88 supplies all data necessary for 

25 bill rendering system 290 to print bills suitable for delivery to subscribers. 
The functions of bill production component 88 are 
described in greater detail in related application, Attorney Docket No. 
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018972.0251 entitled "Method And Apparatus For Processing Billing 
Transactions" which is copending. 

The addressability component 90 is the component 
generally responsible for addressing customer equipment such as 
5 converter boxes. Generally, each converter box has a specific address. 
The addressability component 90 is responsible for sending signals to the 
converter box at that specific address over the WAN 100. The 
addressability component 90 may be responsible for channel lineups, pay- 
per-view connections, TAC, DMX, controller addressing, two way 

10 converter communications, digital compression, netlink functionality, 
automatic box refreshing, bill transmission to a converter box, payment 
from a converter box and converter box assignments, for example. The 
addressability component 90 may also be responsible for other functions. 

The customer support component 92 may be responsible for 

15 various customer related functions. For example, customer support 
component 92 may be responsible for subscriber management, order 
processing, customer service, equipment inventory, customer follow-ups, 
on-line bulletin boards, library topics, phone directory, and tax 
calculations. The customer support component 92 generally comprises a 

20 plurality of OLTP applications. The operation of customer support 
component 92 is described in greater detail below. 

The internal interface component 94 is generally 
responsible for various functions within the corporate structure. For 
example, the internal interface component 94 may comprise an 

25 accounting interface, equipment inventory, payroll/commissions, 
marketing interface, plant management, budget integration, and CIS 
functionality. Internal interface component 94 may also be responsible 
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for other functions as well. 

The reporting component 96 may be responsible for various 
reporting functions such as global reporting, government reporting, MSR 
functionality, tax returns, and ad-hoc capabilities, for example. The 
5 reporting component 96 generally functions to coordinate various data 
across DAS's 104. 

The telephone component 98 may be responsible for various 
telephone oriented functions. The telephone component 98 may be 
responsible for automatic response unit operations, automatic number 

10 indicating screen popping processes, DNIS handling processes, call center 
regionalization, and phone switch interfaces, for example. Other 
telephone, or non-telephone related functions may also be performed by 
telephone component 98. 

The global component 97 may be responsible for various 

15 system- wide functions such as help facilities, security, parameter 

management, utility programs, corporate internal information, computer- 
based training, audits and controls, and address maintenance. Global 
component 97 may also perform other functions. 

A miscellaneous component 99 is preferably provided to 

20 perform other functions not performed by another components of OPS 80. 
For example, miscellaneous component 99 may be responsible for 
disaster recovery, facilities, implementation planning, architecture, GUI 
error handling, GUI validation processing, client hardware specifications, 
ad-hoc reporting tools, reporting standards, technician device UI porting, 

25 dispatch to technician communication, customer tracking, user 

effectiveness, system performance, system enhancement requests, client 
to client communications and international support. Miscellaneous 
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component 99 may also perform other functions. Also, additional 
miscellaneous components 99 may be provided, if desired. 

As discussed above, a plurality of customer service 
processors 102 are preferably connected to OPS 80. Customer service 
5 processors 102 handle requests made at OMS 12. The operations of 
customer service processors 102 are described in greater detail below. 

OMS 12 further comprises a plurality of database access 
systems 104. One of the features of the present invention is that all global 
data is preferably maintained within OMS 12 in database access systems 

10 104. As such, every component on the system may have access to 

information about any other component on system 10. For example, any 
node office system 28 may have access to information about any customer 
of any other node office system 28 in part because that information is 
resident on the database access system 104 which services both node 

15 office systems 28. Because data is stored globally within OMS 12, all 
data is accessed by global parameters also. The uniformity of data access 
also allows for any node office system 28 to access any other node office 
system 28's data because the parameters have been globally defined. Data 
definition is described in greater detail below. 

20 For purposes of ensuring identity of data on the various 

database access systems 104, replication servers 122 may be provided. 
Replication servers 122 ensure that every update of data on one of die 
database access systems 104 also occurs to the data on the other database 
access systems 104. 

25 Database Access System 104 Operations 

Each database access system 104 comprises a plurality of 
data directory servers 106, a plurality of cross reference servers 108, and 
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a plurality of data servers 107. For example, each database access system 
104 may comprise a customer data server 1 10, a dispatch data server 1 12, 
an archive data server 1 14, a billing data server 1 16, a message/notice 
data server 1 18, and a miscellaneous data server 120. Database access 
5 system 104 may comprise more or fewer data servers as needed or 
desired. 

Each processor, subprocessor, and component on WAN 100 
acts as a transaction generator toward database access systems 104. 
These include support systems 32, bill printing system 22, bill payment 

10 system 24, accounting system 26, regional call center processors 43, 
customer service processors 45, main divisional processors 40, 
product/rating subprocessors 41, customer service processors 42, node 
processor 40, technician control subprocessor 52, administration 
subprocessor 54, customer service processors 56, head end controller 62, 

15 OPS 80, product/rating component 82, dispatch component 84, external 
interface sub-processor 86, bill production component 88, addressability 
component 90, customer support component 92, internal interface 
component 94, reporting component 96, global component 97, telephone 
component 98, miscellaneous component 99, and customer service 

20 processors 102. Each of these elements may make a data request over 
WAN 100. All data requests in a preferred embodiment are handled by 
oneoftheDAS's 104. 

Each of these transaction generators is connected via WAN 
100 which is a two-way communication link to the one (or more) DAS's 

25 104. As described above, each DAS 104 may include any number of data 
directory servers 106, but includes at least one. Each data directory 
server 106 in turn is connected via a two-way communication link to 
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multiple data servers 107, for example. Each data server 107 comprises 
one or more databases either as components of a single subsystem 
(processor and database) or through a two way communication link. 
Additionally, each DDS 106 is connected via a two-way communication 
5 link to one or more cross reference servers (X-ref, - X-ref;, where n = an> 
integer) 108. 

In Fig. 4, DDSs 106 are represented as being connected 
over WAN 100. Likewise, DDSs 106 are represented as being connected 
to a plurality of data servers 107. In a preferred embodiment, these 
10 connections are individual connections rather than connections to a 

grouping of DDSs 106. For example, OPS 80 is separately connected to 
each DDS 106. Further, each customer data server 1 10 is separately 
connected to each DDS 106. Alternatively, however, DDS functionally 
may be grouped with common connections to the transaction generators 
15 and/or data servers 107 as indicated in Fig. 4, so long as proper control 
between DDSs 106 is maintained. 

The system of the present invention is designed to manage a 
very large number of OLTP transactions occurring within the system. 
The system of the present invention provides users with the ability to 
20 query across the entire database from any element in the system. 

Similarly, each of the users may update certain data located anywhere 
within the system. 

DDSs 106 respond to transaction generators through 
procedure calls to the DDS. The transaction generators in the system of 
25 the present invention may be any devices capable of receiving input from 
a user and transmitting that input to the Data Directory Servers (DDSs) 
106. In a preferred embodiment, each of the components of the 
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hierarchical control systems 30 comprise transaction generators. At least 
one control application is resident on each transaction generator, 
wherever located, for communication between the DDS(s) 106 and a 
human operator and/or process. As will be discussed in more detail 
5 below, the control application, among other functionality, enables 
updating the internal rules used by DDS(s) 106. 

As described in more detail below, when a transaction is 
generated by a transaction generator and sent to a data directory server 
106, data directory server 106 determines the appropriate data server 107 

10 for execution of the transaction. Preferably, this is accomplished by DDS 
106 consulting the internal rules and identifying the arguments associated 
with the transaction. 

Each of the transaction generators are clients of the DDSs 
106. These terms are used interchangeably herein. Transaction 

15 generators may be dumb terminals (i.e., incapable of performing local 
processing) or they may have various processing capabilities of their own. 
Examples of transaction generators include, without limitation, PC's, 
RISC-based workstations, supercomputers, and local area networks. In 
typical applications, there may be a large number of transaction 

20 generators. Thus, the system is designed as an open platform 

environment which is hardware independent. The transaction generators 
may be homogeneous in terms of interface and operation or they may be 
heterogeneous. In other words, all transaction generators may be of one 
type or there may be a variety of devices interacting with the DDSs 106. 

25 It is also possible to permit customer interaction with the system through 
ARU/ANI (Automated Interactive Voice Response Unit/Automatic 
Number Indicator) units such as ARU 70, and telephone component 98. 



i. 
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In this case, much of the processing may be driven by the telephone 
number retrieved by the ANI when the customer calls into the system. 

DDSs 106 of the present invention function as the middle 
tier of a three tier client/server architecture. As depicted in Fig. 4, more 
5 than one DDS 106 may exist within the operational management system 
12. In such case, each DDS 106 has communication access to all of other 
DDSs 106 as well as to each data servers 107. DDS 106 serve three 
primary functions. After receiving a client request, the selected DDS 106 
first locates the appropriate data server 107 for execution of the request. 

10 It then submits the client request to the selected data server 107 and 
finally DDS 106 returns the result to the submitting client. 

Transaction generators requesting information from the 
databases connect to a DDS 106 prior to accessing data. Through the use 
of internal rules, DDS 106 determines where a remote procedure should 

1 5 be performed in order to complete processing of a transaction. Access to 
DDS 106 may be efficiently implemented through the use of remote 
procedure calls (RPCs) which are identified in tables internal to DDS 106. 
Any of a large number of standards for such RPCs may be used with the 
current invention. 

-° DDS(s) 106 are preferably open server applications that 

provides a mechanism to direct any data request associated with a 
generated transaction to a data server 107 that can service the transaction 
generators 1 requests. Specifically, DDSs 106 may be open servers 
comprising the same or similar hardware as data servers 107 of the 

!5 present invention. Alternatively, DDS 106 may be configured differently 
from the data servers 107. DDS 106 function to analyze the client's data 
request transaction and, based upon the transaction type and a set of rules, 
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directs the request to the appropriate data server 107. The types of 
transactions which are received at DDSs 106 are based upon a set of 
stored procedures recognizable to DDSs 106 and available to the 
transaction generators. 
5 DDSs 106 communicate with a plurality of data servers 107 

each accessing one or more storage devices. In a preferred embodiment 
of this invention the data servers 107 are Sybase SQL Servers which 
execute Sybase remote procedure calls. This invention is not, however, 
necessarily limited thereto and the servers may be of any type so long as 

10 the stored procedures are designed for processing by the particular server 
and the associated database which are selected. It is possible to employ 
any number of data servers 107, transaction generators, and DDSs 106 in 
the operational management system 12 of this invention so long as the 
proper number of communication channels is supplied and supported. 

15 As noted above, more than one DDS 106 may exist in the 

system to provide scalable execution of these functions, each such DDS 
106 being in communication with all transaction generators/clients and all 
servers 107. In an embodiment with multiple DDSs 106, the clients are 
connected with one DDS 106 according to a pre-determined method. 

20 DDSs 106 preferably operate according to a limited number 

of event handlers responsible for processing the requests generated by the 
transaction generators 120 as well as internal requests generated as a 
result of DDS processing itself The event handlers are as follows: 

1 . Start Handler - The start handler provides a convenient and 

25 central location for installing any other event handler routines, building 
any tables necessary for processing client requests and for installing any 
other services that the DDS requires for its functionality. 
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2. Stop Handler - The stop handler is executed when a request 
to shut down the system has been received through a particular request or 
as a result of certain system conditions. 

3. Connect Handler - The connect handler is executed 
5 whenever a client connects to the DDS. 

4 Disconnect Handler ■ The disconnect handler is executed 
whenever a client terminates an active connection to the DDS. 

5 Language Handler - The language handler is executed 
whenever a client application issues a language statement to the DDS. 

10 The language handler in the DDS does nothing since all client requests 
are required to be either registered procedure calls or remote procedure 
calls. 

6. RPC Handler - The Remote Procedure Call handler carries 
the bulk of the load shouldered by the DDS and is the most important 

15 handler for purposes of this discussion. Any client request which is not 
registered in the DDS registered procedure table will generate an RPC 
handler event where the request is analyzed by the RPC event handler and 
acted upon accordingly. 

7. Error Handlers - Several error handlers are installed in the 
20 DDS application to provide information on any failure from the client, 

server and client/server components of the DDS. All error messages are 
logged in the DDS. 

8 Attention Handlers - An attention handler is installed to 
handle disconnects from a client application. The DDS has been set up to 
25 cause all client disconnects to generate an attention event in order to 
determine if the client application has interrupted its connection to the 
DDS. 
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The functionality comprising the operation of the DDS can 
be categorized into three separate classes - the main function, the local 
DDS registered procedures and the utility functions. The main ( ) 
function provides the entry point for all executable C programs. Note that 

5 although the preferred embodiment is formulated using the C and C++ 
languages, the particular invention described herein is by no means 
limited to such a design. The error handlers and the start handler are 
installed in the main function body. These include a set of routines which 
serve to parse input parameters and configuration file attributes in order to 

10 set up any DDS properties. The network listening function is spawned in 
the main function body and sleeps until the DDS application is terminated 
either normally or abnormally. 

The DDS application is dependent on several global data 
tables. These global tables are used to control the navigational decisions 

15 that the RPC Handler needs to direct the client's data requests to the 
appropriate data server in order to complete the data request. 

Service requests originating at the client that are not 
identified as a registered procedure, are treated as remote procedure calls 
and are handled by the RPC Handler. All of the event handlers and 

20 supporting system functions provide a trace log of activities in a locally 
maintained log file. This file is preferably truncated every time the DDS 
application is started. 

Data servers 107 maintain the various data necessary for 
meeting the functions described above and are accessible by each of the 

25 transaction generators through a DDS 106. In a typical implementation, 
data servers 107 are SQL devices which are capable of executing the 
RPCs transmitted by a DDS 106. 
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The databases available to data servers 107 may be either 
homogenous or heterogeneous. In a homogeneous environment, 
particular protocols for accessing each of the databases are consistent 
throughout the enterprise. Conversely, in a heterogeneous environment, 
5 the particulars of database access vary within the enterprise. In a 

heterogeneous environment, it is often desirable, however, to render any 
differences in requirements within the enterprise transparent to user 
working at the client site. That is, a user should not be aware of any 
database heterogeneity and a user request should be processed in a 
10 standard manner across all resources. 

The databases which are accessed in a distributed system 
may all be located together or they may be physically apart. They may be 
at the client location or they may be at an alternate site. Databases may 
be relational databases such as Sybase (a trademark of Sybase, Inc.) or 
15 they may be as simple as a series of flat files. 

DDSs 106 interface with a control application which resides 
on each transaction generator. The control application functions to allow 
a system operator to store, update, and modify stored procedures available 
to the transaction generators. This is typically accomplished by 
20 downloading the update to the X-Ref Server 1 08 which loads the new 
rules base into the DDSs 106 at DDS startup. 

OPS 80 also includes one or more X-Ref Servers 108. X- 
Ref Servers 108 function as a resource available to DDSs 106 for 
determining where specific data resides in the system and for storing the 
25 rules base which is loaded into DDSs 106 at DDS start-up. X-Ref Servers 
108 contain a variety of global tables which are continually updated as 
data is added, updated and deleted within the system. 
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In a preferred embodiment, DDSs 106 access XRef 
Servers) 108 at startup to access database information necessary for the 
operation of DDSs 106. After the start-up tasks are complete, normal 
client requests may be processed by DDSs 106. Alternatively, DDSs 106 
5 may access XRef Server(s) 108 (or any other device containing the 
required data) as requests are submitted to DDSs 106. 

Client requests are initiated at the transaction generators and 
transmitted to a DDS 106. Once it has received the data request, the DDS 
application consults the DDS Server Table (a global table) which 

10 identifies all of the available and accessible data servers 107. There is 
also provided an XRef Server Table (global) which identifies all known 
and accessible XRef Servers 108. An additional global table is the Error 
Message Handler Table which maintains all error handler messages. All 
of the global tables defined in DDS 106 provide feature functionality to 

1 5 support the access related to these tables. 

The transaction generators make requests for reads, writes, 
and updates through DDS 106. As discussed above, once a request is 
received, DDS 106 determines the set of potential data servers which may 
execute the request and pseudo randomly selects one or more servers 

20 from that set for servicing. Alternatively, various, non-random and semi- 
random methods for selecting the subset of potential data servers may be 
used. Examples of such methods include those relating to current server 
loads (load balancing) and those relating to queuing theory in general. 
The subset of servers which are available to process the request may be 

25 determined in one of two ways as discussed above. In a first 

embodiment, global tables are loaded from XRef Server 108 into internal 
DDS memory at DDS startup. In a second embodiment, no such loading 
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occurs at startup - rather, upon receiving a client request, DDS 106 
submits a request to XRef Server 108 in order to retrieve the necessary 
data. In either embodiment, DDS 106 has available to it the necessary 
rules base and other data which is required to determine the type of 
5 transaction (including the data required and the locations of that data) and 
to select the appropriate data server(s) 107 for processing the transaction. 
Next, the request is submitted to the selected data server(s) which process 
the request and returns a result set to DDS 106 which may then perform 
additional operation(s) on the data prior to passing the final result set back 
10 to the transaction generators. Alternatively, the result set may pass 
through DDS 106 to the transaction generators without any additional 
processing on the part of DDS 106. The latter situation is generally 
termed "pass-through mode". 

After a request has been serviced and the result set has been 
1 5 returned to the transaction generators, DDS 106 may receive another 

request and process it in accordance with the above procedure. In such an 
embodiment, the DDS 106 does not begin processing a new request until 
it has completed processing of the prior request. In another and preferred 
embodiment, a single DDS 106 processes multiple client requests 
20 concurrently exploiting the availability of numerous resources for 
processing large numbers of transactions. 

The operations of DASs 104 according to one embodiment 
of the present invention are described in greater detail in Application 
Number 08/405,766 entitled "Method And Apparatus For Transaction 
25 Processing In A Distributed Database System," which was filed on March 
17, 1995, which is copending and which is hereby incorporated by 
reference. 
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Fig. 5 depicts another configuration illustrating the 
connections of the various components of DAS 104. In this embodiment, 
two DAS's 104 are provided, one at Denver, for example, and one at 
Dallas, for example. The DAS's 104 are distributed over WAN 100. 
5 Customer service processors 102 are also indirectly connected to WAN 
100 to enable access to DDS's 106, XRef servers 108 and the various data 
servers 107 which in this embodiment may comprise customer data server 
1 10, dispatch data server 1 12, bill data server 116 and miscellaneous data 
server 120. Several of the external processors 32 may also be connected 
10 to WAN 100. For example, bill printing system 22 and accounting 
system 26 may be provided with access to DDSs 106. 

In the embodiment of Fig. 5, there are eight DDSs 106 
provided at each location and two XRef servers 108. These numbers may 
be varied such that more or fewer DDSs 106 may be provided or more or 
15 fewer XRef servers 108 may be provided. 

Three types of connections may be provided: 

1) a client to DDS connection; 

2) a DDS to data server connection; and 

3) a replication server to data server connection. 
20 In Fig. 5, the various connections are depicted. As 

described above, in a preferred embodiment, each of the components are 
directly connected. For example, each customer service processor 102 is 
preferably directly connected to a DDS 106. Also, each data server 107 is 
preferably connected directly to a DDS. A replication server is a server 
25 that generates a duplicate copy of the information located on a primary 
server. In a preferred embodiment, when at least two DAS's 

104 are provided, each DAS 104 has an associated replication server 107. 
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For example, in Fig. 5, CUSTD_2 may have the same information as 
CUSTL_2. In this embodiment, if a customer service processor 102 
requests information from DDSDJ, for example, about a customer which 
is stored on CUSTD_2 and the DDSDJ is unable to access that data 
5 server (for whatever reason, e.g., transmission problems), the DDSDJ 
may access the required data from CUSTL_2 in Dallas. Therefore, the 
CUSTL 2 is a replication server for DDSDJ and all other DDS's at the 
Denver location. 

Many of the operations of this system are understood upon 

10 an explanation of the functions of the components. Product/rating 
component 82, product/rating subprocessor 53, and product/rating 
subprocessor 41 interact over WAN 100 with OMS 12 in a manner which 
highlights various features of the present invention. 
Product/Rating Component 

15 As described above, in general product/rating component 82 

is responsible for product definition, pricing, packaging and the like. 
According to a preferred embodiment of the present invention, 
product/rating occurs strictly according to the hierarchical control 
established in system 10. OMS 12 has ultimate control over definition of 

20 any product provided by any node office system 28 on OMS 12. 
Operational Management System Product Definition 

According to a preferred embodiment of the present 
invention, a user having access to operational management system 12 
defines a product and product parameters which become universal 

25 information for all cable systems, i.e., node systems 28 on OMS 12. In a 
preferred embodiment, products are defined at the highest level, for 
example at the corporate level, before the same product may be defined at 
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any lower level. The information defined at the highest level is preferably 
input by a limited number of individuals having access to that level, for 
example, specified corporate personnel, and is designed to provide the 
highest level of priority and security. The product definitions and product 
5 parameters defined at the highest level, such as the corporate level, define 
the standards that are adhered to at all lower levels of product definition. 
Product Parameters 

In a preferred embodiment, a product is defined by a 
product ID which may be a system generated number that relates to the 

10 defined product; a product name which must be unique from all other 
defined products; a product start date and stop date; product category and 
product type for example. 

There may be any number of product categories including 
entertainment, pay-per-view, package, equipment rental, merchandise, 

15 work order, and special, for example. Within the entertainment product 
category, there may be several product types including basic, expanded 
basic, game, premium, and audio, for example. Within the pay-per-view 
product category, there may be several product types including PPV 
event, PPV movie, PPV adult, and PPV game, for example. Within the 

20 package product category, there may be several product types including 
recurring and one-time, for example. Within the equipment rental product 
category, there may be several product types including converter, remote 
control, DMX tuner, and DMX DJ remote, for example. Within the 
merchandise product category, there may be several product types 

25 including equipment, remote control, game, guide, DMX tuner, DMX DJ 
remote, coax cable, a/b switch, splitter, and accessory, for example. 
Within the work order product category, there may be several product 
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types including installation, service change (upgrade, downgrade or 
sidegrade), hourly service charge, restart, trouble call, and transfer, for 
example. Within the special product category, there may be several 
product types including guide, club membership, home wiring 
5 maintenance, equipment maintenance, and credit card membership, for 
example. 

General Product Definition 

In general, products are defined by the creation of a record 
by product/rating component 82 and stored in one or more of data servers 

10 107. For example, product definition records may be stored in the 
customer data server 1 10 or may be distributed across several servers. 
Some fields of the product record may be required regardless of the 
product category. For example, product name, product long name, 
product category, product type, business unit, bill statement name, 

15 product start date, product stop date, revenue ID, account type, offer 
method, corporate suggested price, corporate minimum price, and 
corporate maximum price may be mandatory product parameters. 

Other fields may also be completed for the various types of 
product categories. For example, these fields may include channel 

20 position, range, franchise rate, channel number, price effective date, 
network, frequent buyer points, marketing description, internal, 
commission, inclusions/exclusions, equipment dependencies, 
authorization codes, division suggested price, division minimum price, 
division maximum price, state suggested price, state minimum price, state 

25 maximum price, multi-outlet discount, business unit approval code, 
deferred rate, task code, force monthly bill, charge before, studio, 
distributor, rating subject, free view minutes, event ID, event start 
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date/time, even stop date/time, event duration, ARU price, ANI price, 
impulse price, club price, CSSR price, event price effective, date/time, 
employee price, base event number, event authorization/controller, event 
number, cancel date/time offset, start order date/time offset, and stop 
5 order date/time offset. Other parameters may also be provided to defme 
products. 

Definition Of Product At Highest Level 

Operational management system 12 in a preferred 
embodiment defines the highest level of priority in system 10. Access to 

10 OMS 12 is restricted according to predefined roles. For example, the 
corporate office may have direct access to OMS 12. Certain individuals 
having a password which is defined in product/rating component 82 have 
the authority to define a product which may then be made available to the 
various node systems 28 and intermediary systems distributed over 

15 system 10. These individuals may then be users on OMS 12 and may 
define a product 

Every user of system 10 has an associated authorization 
indicating the business level at which product definition may be made. 
For example, a small set of people may have corporate level authorization 

20 and may defme products at the corporate level, or any lower level. 
Others, such as personnel at the various division offices, may have 
authorization at the division level and may define products at the division 
level, or any lower level. Others, for example, personnel at the various 
state offices, may have authorization at the state level and may define 

25 products at the state level, or any lower level. Others, for example, 
personnel at the various franchises, may have authorization at the 
franchise level and may define products at the franchise level, or any 
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lower level. Others, for example, personnel at the various node offices, 
may have authorization at the node level and may define products at only 
that node level. Authorization is not limited to geographic location, 
however, and it is possible for a user at a node to have corporate, 
divisional, state, or franchise level authorization. It is also possible for a 
user at the corporate location to have only authorization for a particular 
node. Due to a possible wide geographic distribution of office systems, 
however, for the sake of explanation, it may be assumed that most users 
have authority at the level corresponding to the office system from which 
they access system 10. 

When a corporate authorization level user wishes to define a 
new product, first the user makes a request of product/rating component 
82 to define the new product by a product name. To avoid potential 
duplication of names which could lead to confusion, product/rating 
component 82 initiates a search to determine if a product having the 
requested product name exists. Product/rating component 82 may send a 
request to database access system 104 which may supply the requested 
information. Because product names are preferably unique over the entire 
system, only one product may have the requested name. In a prefeiTed 
embodiment, when a corporate user is redefining a predefined product, a 
screen enabling the user to select the product from a list of defined 
products may be provided. 

If the product requested is not identified, the user may 
define the product. A new product may be defined when product/rating 
component 82 creates a new record with the necessary product 
parameters. This record then becomes available at all lower levels for 
product definition and revision, subject to the conditions and limitations 
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placed on the product at the highest level. 
Lower Level Product Definition 

As stated above, in a preferred embodiment, products may 
only be defined at lower levels if that product has been defined at the 

5 highest level. For example, a local cable operator cannot offer HBO as a 
product unless the corporate level has defined HBO as a product. Many 
parameters about a product may differ at the lower levels of the 
organization. For example, a node office in New York City may charge 
$8.00 for HBO whereas a node office in a much smaller community may 

10 charge only $5.00 for HBO. Nonetheless, any parameter of a product at 
the local level must fall within the parameters established at every higher 
level. 

Therefore, each actual provider of services must define the 
product also. Node office systems 28 and franchise systems 20 may offer 

15 services, for example. In order for these offices to provide the products 
defined at the highest level, the products must also be defined at the level 
of their office. Product definition at the intermediate levels such as 
division and state offices may also be provided if the division and state 
offices wish to maintain greater control over product definition than that 

20 provided at the highest or corporate level. 

To define a product at a lower level, the user requests a 
product definition from the product/rating component at its level. For 
example, if a user at the division level wishes to define a product for the 
division level, then product rating component 41 may be used. If a user at 

25 the node level wishes to define a product for the node level, 

product/rating component 53 may be used. Other product/rating 
components may also be used, as long as the user only defines a product 
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The product/rating component servicing the user request 
then makes a database request to database access system 104 to determine 
if the product is defined at the highest level. If a product is not identified, 
5 the user is notified that the product does not exist or is no longer active. 

If the product is identified, then that product has been 
defined at the highest level and therefore, the user may proceed to define 
the product for a lower level. The user is then prompted to select the 
business unit at which the product definition or revision is requested. For 
10 example, the permissible business units may include corporate, division, 
state, franchise, or node. When the business unit is identified and 
validated to ensure that the user has the authority to make product 
definition/revisions at the requested business unit, the product/rating 
component initiates a search through database access system 104 to 
1 5 identify a record for the product at the desired business unit. 

If a record for the product at the requested business unit 
level is identified, the product parameters from that record are presented 
and the user is provided with the opportunity to modify authorized 
parameters. Because certain parameters for the lower level record were 
20 defined at the highest level, those parameters may not be altered by the 
user at the lower level. Further, certain parameters for the lower level 
record may have been defined at a higher level (but not the highest level). 
Those parameters may not be altered by the user at the lower level either 
For example, if a product has been defined at the corporate, 
15 division, state, and franchise level, a product record would have been 
created for the product at each of those levels. The product record for the 
division level would have the same completed parameters as the product 



7/20/06, EAST Version: 2.0.3.0 



WO 97/24691 



PCT/US96/20125 



44 

record for the corporate level and would likely include several other 
completed parameters. The product record for the state level has the 
completed parameters from the corporate level and the division level and 
may include several other completed parameters. The product record for 
5 the franchise level has the completed parameters from the corporate level, 
the division level, and the state level and may include several other 
completed parameters. For a request to define a product at the node level 
the product/rating component generates a new record for the product at 
the node level having the completed parameters from the corporate, 

10 division, state and franchise level 

If a record does not exist at the desired business unit for the 
selected product, the user may define the product at the desired business 
unit Product definition at a level lower than the highest level occurs 
when the product/rating component generates a new record for the 

15 product at the specified business level. This record is copied for the next 
highest level at which the product has been defined. Additional 
parameters to be completed are then provided to the use in a graphical 
interface for the user to complete. 

If price information for the lower level is input which 

20 confines the limits imposed at a higher level of authorization, those price 
parameters must be modified in all records for all levels below the 
defining level. For example, if a product is defined at the division level 
with a minimum and maximum price which are higher and lower, 
respectively, of the minimum and maximum price of the corporate level 

25 record, then all product records at the state, franchise and node levels 
must be modified to include this information. Further, all pricing 
information at those levels must be verified to ensure that they are still in 
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compliance with the hierarchical structure. 

For example, if HBO has a minimum price of $5.00 and a 
maximum price of $15.00 at the corporate level and at a node level, the 
price may be set at $6.00. If a division record is modified such that the 
5 division minimum price is $8.00, then the price at the node level would 
not longer be valid and would have to be modified. 
Franchise Level Specifics 

Because timing is different across the country based upon 
the time zone of the business unit, at the franchise level, when certain 
10 products such as pay-per-view events are defined, the product/rating 
component adjusts the times from the corporate, division, and state 
product definitions for the event. 

Product Definition Example 

Assume a system having a corporate office, five division 
1 5 offices, one hundred state offices, 250 franchises and 500 nodes. Each 
division covers ten states, each state covers five franchises and each 
franchise has two nodes. Suppose a user at the corporate level accessing 
OMS 12 defines a product called ABC 123 which is to be a new 
educational tutoring premium network. The user inputs a request through 
20 a customer service processor 1 02, for example. The user is then 

prompted to enter the required parameters to define a product. In one 
embodiment, those parameters may be 

product name = ABC 1 23 ; 
bill statement name = ABC 123; 
25 product long name = ABC 1 23 Educational Channel; 

product category = entertainment; 
product type = premium; 
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product start date 
product stop date 



= 01/01/96; 
= 12/31/16; 
= $1.00; 
= $10.00; 



corp. nun. pnce 



corp. max. price 



corp. sug. pnce 



= $3.00. 



When the user has input into die customer service processor these 
parameters, product/rating component 82 generates a record to be stored 
by data access system 104. Data access system 104 and product/rating 
components 82 also generate a product ID which may be a number which 
10 uniquely identifies the product. The corporate user may also enter other 
parameters which may be provided for the product. 



all lower levels may define this product at their respective level. All 
lower level definitions of a product must comply with the boundaries and 

15 conditions established at the corporate, or highest, level authorization. 
For example, suppose after a year, response to the ABC 123 channel is 
good for node systems 28 within a particular state, State A, but studies 
indicate that the pricing for that particular state is a little too high. 
Further, the state level determines that the ABC 123 product is a valuable 

20 premium channel and that the cost should be minimized for the cable 
systems in its state. The state level determines that the maximum price 
for any system in its state should be set at $2.00 instead of $10.00 as 
defined at the corporate level as of 01/01/97. A user having authority at 
State A level may define the ABC 123 product for State A through a 

25 customer service processor 42 at state office system 18 located in State A, 
for example. A user having State A level authority may also use any 
other customer service processor including one at OMS 12. 



Once ABC 123 is defined as a product at the corporate level, 
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Product/rating component 41 at state office system 18 may 
be used by the user to request the creation of the State A level ABC 123 
product record. Product/rating component 41 then may access DDS 106 
to retrieve a record for ABC 123 at the next highest level at which the 
5 product is defined and which is associated with the particulate state level 
at which the user has authority. A State A level ABC 123 product record 
may be generated by copying ABC 123 record from the next highest level 
product record which is retrieved from DDS 106. For example, if the 
product has only been defined at the corporate level, the corporate level 
1 0 product record for ABC 1 23 is copied to generate a State A level ABC 1 23 
product record. In addition, additional state level parameters may be 
provided. Each state level may define these parameters differently such 
that 50 different state level product records may exist for a single product. 
Therefore, the State A level ABC 123 product record may include the 
15 following parameters: 

product name = ABC 1 23 ; 

bill statement name = ABC 123 channel; 

= ABC 123 Educational Channel; 
= entertainment; 
= premium; 
= 01/01/96; 
= 12/31/16; 
= $1.00; 
= $10.00; 
= $3.00; 
= $1.00; 
= $2.00; 



product long name 
product category 
product type 
product start date 
product stop date 
corp. min. price 
corp. max. price 
corp. sug. price 
state min. price 
state max. price 
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state sug. price = $ 1 .00; 

state prod, start date = 01/01/97; 

state prod, stop date = 12/31/16. 

Suppose that on February 1, 1996, a franchise, Franchise 
5 Apple, in State A which did not previously provide ABC 123 decides to 
provide ABC 123. A user having authority for Franchise Apple may 
request a product definition for ABC 123 for Franchise Apple. For 
example, the user may use product/rating component 53 at Franchise 
Apple's franchise system 28 to create a Franchise Apple level product 
10 record for that franchise system 20. Product/rating component 53 first 
retrieves the State A level ABC 123 product record and generates a new 
record having the same parameters as the State A level ABC 123 product 
record. Then the user is prompted to complete additional information for 
that particular franchise. Other franchises in State A may define the 
15 product differently depending on the individual needs. A franchise level 
product record may be as follows: 

product name = ABC 1 23 ; 

bill statement name = ABC 123 channel; 

product long name = ABC 123 Educational Channel; 
20 product category = entertainment; 

product type = premium; 

product start date =01/01/96; 

product stop date =12/31/16; 

corp. min. price = $1.00; 
25 corp. max. price = $10.00; 

corp. sug. price = $3.00; 

state min. price = $ 1 .00; 
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state max. price = $2.00; 
state sug. price = $ 1 . 00; 
state prod, start date = 01/01/97; 
state prod, stop date = 12/31/16; 
franchise rate = $ 1 .50; 
effective date = 02/01/97; 
fran. prod, start date = 02/01/97; 
fran. prod, start date = 12/31/97. 



10 



Suppose on July 1, 1996, the division office overseeing the 
state and franchise systems in this example determines that ABC 123 is 
not viable in its division unless the price is at least $2.50. The division 
office may define the product at the division level. The record for the 
division level product is copied from the corporate level which is the next 
15 highest level where the product is defined. A division office user may 
then complete division level specific parameters. The division level 
ABC 123 product record may be as follows: 

product name = ABC 1 23 ; 
bill statement name = ABC 1 23 ; 
20 product long name = ABC 123 Educational Channel; 

product category = entertainment; 
product type = premium; 

product start date = 0 1/0 1/96; 
product stop date = 12/3 1/16; 
25 corp. min. price =$1.00; 

corp. max. price = $10.00; 
corp. sug. price = $3.00; 
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div. min. price = $2.50; 
div. max. price =$10.00; 
div. sug. price = $5.00. 



5 Once the division level product has been defined, all lower 

levels must be updated, particularly because the new division minimum 
price has been set at a level higher than the state maximum price. 
Because the user at the division level may change records for all lower 
levels, the division level user may simply change the state level and 

10 franchise level product records such that the state maximum price is 
$2.50, for example. Product/rating component 42 may perform this 
automatically, for example, through data access system 104. 
Alternatively, authorization may be required from the division user to 
ensure that the division user wishes to override the state level product 

15 definition. Whenever a state level definition has been altered, state office 
system 18 for which the product was defined is notified of the change. 
Package Definition 

A package is one particular type of product for which 
additional information is entered to define the product. Essentially, a 

20 package is a collection of two or more individual products (preferably not 
other packages) that are discounted and offered to customers as a single 
product. The individual products to be included in a package must be 
defined before they can be included as a package. For example, in order 
to have a package including HBO, HBO must be defined as an individual 

25 product in the manner set forth above. The combination of individual 
products to create packages is specifically designed to provide a price 
differentia] and entice customers to buy products. Further, each package 
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is preferably unique in that it contains a different combination of 
individual products. 

Package Searching 

As with a product definition, the initial step of package 
definition is for product/rating component 82 to search for the package. 
Packages can be identified in two ways: 1) search for a package via the 
package name or package long name, and 2) provide a selectable list of all 
available packages. Package lists are presented in alphabetic order based 
on the long name. The ability to present the package list by package 
name or package long name/package type is also provided. 

In addition, a user can search for packages containing any 
combination of individual products. This search requires the user to 
select one or more individual products. For example, a user may select 
HBO and Showtime. Upon such a request, all packages containing HBO 
and Showtime are found and displayed for the user to choose from. If a 
package is not found in the search, a new package may be defined. 

Example: Find and display all packages containing 
HBO, Showtime and Cinemax. 

1) Enter "HBO", Showtime" and "Cinemax" 

2) Search all packages that contain HBO, Showtime and 

Cinemax 

3) Display all packages that contain HBO, Showtime and 

Cinemax 

End Result: 

Package Name Package Comp onent 

HBO/SHO/MAX HBO, Showtime, 

Cinemax 
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The Movie Channel 



HBO, Showtime, 



Cinemax 



The Complete Package 



Encore, Starz 
Basic, Expanded Basic, 
HBO, HB02, Showtime, 
Showtime2, Cinemax, 
Encore, Starz 



10 



15 



20 



Package Components 

The individual products that make up a package are 
preferably either recurring or one-time products. Recurring products are 
billed in regular intervals (e.g., monthly, quarterly, etc.) and contain 
individual subscription products, or products with recurring charges. 
When a package is defined as a recurring package, each and every 
package component is preferably a recurring charge. One-time charge 
products are applied once on a customer's account. A one-time package 
contains individual one-time products, or products with a one-time 
charge. When a package is defined as a one-time package, each and every 
package component is preferably a one-time charge. One-time charges 
include PPV events, work order (e.g., install, change of service, etc.) and 
merchandise. 

Because packages are products, the procedures for defining 
products may also be followed to define packages. Therefore, packages 
are also defined with strict adherence to the business hierarchy. The 
highest level of control, for example, the corporate level, defines the 
accounting, billing and pricing standards for all packages. A package 
must exist at the highest level before it can be defined at any lower level 
in the business hierarchy. The lower levels may narrow the pricing 
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standards and may identify the areas in which the package will be 
available. The franchise level establishes a specific package price, just as 
it establishes specific individual prices. 

Packages may be defined by a package name, package long 
5 name, package category (automatically set to "package"), package type 
(either recurring or one-time), corporate package minimum price, 
corporate package maximum price, account type, package components, 
package start date, package stop date, package price effective date and 
package allocation, all of which may be input by a user at the highest 
10 level as set forth above with respect to product definition. Product/rating 
component 82 then determines if the package is valid. First, it ensures 
that no other packages exist with the same products. Then, it ensures that 
the stop date of all of the products which form the package components is 
at least as late as the package stop date. Further, product/rating 
1 5 component 82 determines whether all of the products which form the 
package components have a product type which is the same as the 
package type, i.e., that all products are recurring for a recurring package 
and all products are one-time for a one-time package. 

Revenue for individual products may need to be determined 
20 from the package. In other words, for accounting purposes, it may be 
necessary to know how much HBO is generating even if HBO is part of a 
package which generates a single price for all products included therein. 
For this purpose, package definition also includes package allocation 
parameters. 
-5 Package Allocation 

The package allocation parameters contain the package 
component information and associated dollar amounts and percentages. 
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The package allocation parameters may include package component, 
revenue split, revenue split percentage, and fixed revenue indicator. The 
package component parameter contains the individual product 
components that are part of the package (e.g., HBO, Showtime, Basic, 
5 Expanded Basic, Terminator 2, WWF Wrestlemania, etc.). Additionally, 
for each product component one of three revenue indicators (revenue 
split, revenue split percentage, or fixed revenue indicator) may be 
defined. 

Revenue split indicates that the product has a specific dollar 
10 amount. For example, if a package containing two components is defined 
and priced at $12.00, then the revenue split for the first package 
component can be $7.00 and the revenue split for this second package 
component can be priced at $5.00. 

Revenue split percentage parameter defines the percentage 
15 of a package price that should be attributed to the individual product. If a 
package containing two individual products is defined and each individual 
product should make up 50% of the total price, then each revenue split 
percentage would be set to 50%. 

Fixed revenue indicator may be used to indicate that the 
20 revenue should be fixed. Some package components are defined as only 
having one selling price regardless of what franchise they are sold in or 
what package they are a part of. An example is Encore. When Encore is 
sold, a-la-carte or part of a package, it is sold for $1 .00. 

There are two methods of providing the revenue splitting 
25 information: the suggested retail price/revenue split percentage method 
and the revenue split method. 

Suggested Retail Price Revenue Split Percentage Method 
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In this method, for each component, a revenue split 
percentage is defined as a package parameter. Also, a corporate 
suggested retail price is defined as a package parameter. The individual 
revenue splits for the products are then determined based on the 
5 percentage parameter times the corporate suggested retail price. 
Example 

1 ) Package components HBO, Showtime and Cinemax 
are collected into a package. 

2) Suggested retail price is entered as $20. 

0 3) HBO is given a revenue split percentage of 40%, 

Showtime is given a revenue split percentage of 40% 
and Cinemax is given a revenue split percentage of 
20%. 

4) The revenue split percentages total 100% (40% plus 
5 40% plus 20%). 

5) The HBO revenue split is calculated to be $8 (40% 
multiplied by $20), the Showtime revenue split is 
calculated to be $8 (40% multiplied by $20) and the 
Cinemax revenue split is calculated to be $4 (20% 

) multiplied by $20). 

Revenue Split Method 

In this method, revenue splits are directly defined. The 
suggested retail price is then totaled from the revenue split definitions. 
The revenue split percentages are then determined by simply dividing the 
suggested retail price with the revenue splits for the individual product 
components. 

Example 
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1) Package components HBO, Showtime and Cinemax 
are collected into a package. 

2) HBO is given a revenue split of $8, Showtime is 
given a revenue split of $8 and Cinemax is given a 

5 revenue split of $4. 

3) The suggested retail price is calculated to be $20 ($8 
plus $8 plus $4). 

4) The HBO revenue split percentage is calculated to be 
40% ($8 divided by $20), the Showtime revenue split 

10 percentage is calculated to be 40% ($8 divided by 

$20) and the Cinemax revenue split percentage is 
calculated to be 20% ($4 divided by $20). 
Effect Of Fixed Revenue Indicator 

When a fixed revenue indicator is associated with a package 
15 component, the revenue split is entered for the package component. 
When this occurs, the package component's revenue split percentage is 
set to 0% and cannot be changed as long as the fixed revenue indicator 
exists. In addition, the calculation of the revenue and revenue split 
percentages are impacted by this fixed revenue indicator as follows: 
20 If dollar amounts are entered for the other package 

components, the suggested retail price is determined by summing all 
package component revenue splits. The revenue split percentages are 
then calculated by first subtracting the revenue split of the package 
component with a fixed revenue split from the suggested retail price. 
25 Then, the other package components are divided by the previously 
calculated number to determine revenue split percentages 
Example 
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1) Package components HBO, Showtime and Encore are 
collected into a package. 

2) The fixed revenue indicator is associated with Encore and 
set at $1.00. 

3) Encore is given a revenue split of $ 1 . 

4) Encore's revenue split percentage is automatically set to 
0%. 

5) HBO is given a revenue split of $5 and Showtime is given a 
revenue split of $4. 

6) The suggested retail price is calculated to be $10 ($1 plus 
$5 plus $4). 

7) The Encore revenue split of $1 is subtracted from the 
suggested retail price of $10. $9 is then used to determine 
the revenue split percentages for the remaining package 
components. 

8) The HBO revenue split percentage is calculated to be 55.5% 
($5 divided by $9) and the Showtime revenue split 
percentage is calculated to be 44.4% ($4 divided by $9). 

If a suggested retail price is entered, the user is required to 
enter percentages for each package component (excluding the package 
component with a fixed revenue split). Once the entered percentages 
equal 100%, the revenue split amounts are then calculated. The first step 
is to subtract the revenue split of the package component with a fixed 
revenue split from the suggested retail price. The revenue split 
percentages are then multiplied by the previously calculated number to 
determine the revenue splits. 
Example 
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1) Package components HBO, Showtime and Encore are 
collected into a package. 

2) The fixed revenue indicator is associated with Encore. 

3) Encore is given a revenue split of $ 1 . 

5 4) Encore's revenue split percentage is automatically set to 

0%. 

5) Suggested retail price is entered as $10. 

6) HBO is given a revenue split percentage of 60% and 
Showtime is given a revenue split percentage of 40% 

1 0 7) The Encore revenue split of $ 1 is subtracted from the 

suggested retail price of $10. $9 is then used to determine 
the revenue splits for the remaining package components. 
8) The HBO revenue split is calculated to be $5.40 (60% 
multiplied by $9) and the Showtime revenue split is 

15 calculated to be $3.60 (40% multiplied by $9). 



Changing Revenue Splits and Revenue Split Percentages 

In a preferred embodiment, revenue splits and revenue split 
20 percentages may only be modified at the highest level of control, for 

example, the corporate level. When a lower level business unit, such as a 
division, changes the suggested retail price, the revenue splits at that level 
are automatically recalculated based on the new suggested retail price and 
the revenue split percentages. All calculated revenue splits are rounded to 
25 the nearest penny to ensure the total of the revenue splits total the 
suggested retail price. 

Three methods of changing this information at lower levels 
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exist once the package is initially defined. The three methods are: 

1. A change to the suggested retail price at any level 
which causes the product rating to recalculate the 
revenue splits using the already defined revenue split 

5 percentages. 

2. A change to the revenue split amounts at the highest 
level which causes product/rating component 82 to 
recalculate the suggested retail price and then 
recalculate the revenue split percentages. 

10 3 . A change to the revenue split percentages at the 

highest level which causes product/rating component 
82 to recalculate the revenue splits using the already 
defined suggested retail price. 
The following provides an example of method number one. 

15 Example 

1) A state business unit changes the suggested retail 
price from $20 to $24. 

2) The HBO revenue split is recalculated to be $9.60 
(40% multiplied by $24), the Showtime revenue split 

20 is recalculated to be $9.60 (40% multiplied by $24) 

and the Cinemax revenue split is recalculated to be 
$4.80 (20% multiplied by $24). 
Package Savings 

In a preferred embodiment, product/rating component 82 
25 determines package savings parameters for the defined package. The 
package savings parameters indicate the savings this package offers as 
compared to the individual product prices. These parameters may include 
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individual product price, individual product price total, dollar savings and 
percentage savings. The individual product price is the price charged for 
the package component if it was sold a-la- carte. The individual product 
price total is the total dollar amount of all the package components if they 
5 were sold a-la-carte. The dollar savings is the savings, in dollar amount, 
of this package as compared to the total cost of all the package 
components if they were sold a-la-carte. The percentage savings is the 
savings, as a percentage, of this package as compared to the total cost of 
all the package components if they were sold a-la-carte. The package 

10 savings parameters are particularly useful for customer service 
representatives who are attempting to sell the packages. 
Multi-Outlet Pricing 

Some packages may contain parameters for multi-outlet 
pricing. To determine if the package is eligible for multi-outlet pricing, 

15 the process evaluates the product category, offer method and a regulated 
flag for each package component. If any of the package components are 
categorized as entertainment or equipment and have an offer method of 
charge-by-outlet, multi-outlet pricing can be defined. Multi-outlet pricing 
is defined for a package by using the multi-outlet pricing defined for an 

20 individual product. The option then exists to change the multi-outlet 
pricing once it is populated with pricing data from the individual product 
level. The following describes the two possible scenarios regarding 
multi-outlet pricing. 

Scenario 1 

25 All of the package's components are unregulated and the 

offer method for one or more package components is charge-by-outlet (set 
during product definition). Multi-outlet pricing can be a flat dollar charge 
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only. The multi-outlet price can be defined as a dollar amount that is 
equal to or less than the package rate. 

Scenario 2 

The package's components consist of regulated and 
5 unregulated products and the offer method for one or more package 
components is charge-by-outlet (set during product definition). Multi- 
outlet pricing can be a flat dollar charge only. 
Example 

The following example shows how a package can have 
1 0 multi-outlet discounts with both regulated and unregulated products. 

Outlet 1 Outlet 2-3 Outlet 4-5 

Basic $10 $0 $0 

HBO $6 $4 $2 



15 



Showtime $6 $4 $2 

TOTAL $22 $8 $4 



Multi-outlet pricing in the above example can be defined in 
two ways. The first is to use the package multi-outlet pricing information 

20 that was automatically populated with the individual product multi-outlet 
pricing information. The second way is to change the revenue split for 
each package component for additional outlet ranges (except for Basic 
since it is a regulated product). The individual dollar amounts are then 
summed to determine the total cost to the customer to have the package 

25 on additional outlets. 
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Package Termination 

Packages can be terminated in two ways. The first, and 
most common, is based on the entered stop date when a package is 
initially defined. Once the current date is greater than the package stop 

5 date, the package is no longer offerable to customers. The second way to 
terminate a package is to actually delete the package. This deletion may 
only occur if the package has never been associated with any customer's 
account. Once a package has been associated with at least one 
customer's account, the package cannot be deleted. It's stop date can be 

10 changed, based on the previously defined rules, to a date that no longer 
allows the package to be offered to customers. 
Package Redefinition Once Offered 

In a preferred method, once a package is defined and 
customers begin receiving it, no package components can be added or 

15 deleted. If active or inactive customer accounts are currently associated 
with a package, then no package components can be deleted (i.e., 
removed). In addition, components cannot be added or deleted once a 
package has been defined at the corporate level and lower levels begin 
redefining the package. 

20 Hierarchical Control Generally 

Product definition provides one example of how OMS 12 
controls the operations of every other hierarchical system 30. Unless a 
product is defined by OMS 12, none of the hierarchical systems 30 may 
define that product. In such a manner, oversight of the operations of 

25 subsidiary components of system 10 is very efficient. 

Hierarchical control by OMS 12 is preferably also provided 
for every other system of system 10. For example, dispatch component 
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84 preferably provides for hierarchical control of all dispatch operations 
on system 10. If the highest level of control determines that a certain 
repair unit in Denver should be sent to a certain customer, a user on OMS 
12 having highest level access, such as a corporate user, may enter such 
5 an order. Lower levels of control, even the franchise or node level, may 
not override this order in a preferred embodiment. 

Also, for example, if at the division level, for example, it is 
determined that all calls from a specified customer or customers in that 
division should be handled at one of regional call centers 14, a division 
1 0 level user may enter such a command, and all telephone calls identified 
by telephone component 98 shall be transferred to a customer service 
processor at regional call center 14. Such a decision may be made, for 
example, if a particular customer only speaks Spanish and none of the 
operators at the franchise or node associated with the customer speak 
1 5 Spanish, but several regional call center operators speak Spanish. 

As can be seen, system 10 provides for top level, i.e., OMS 
12, control over operations of system 10. Additionally, intermediate 
levels of control are provided by division office systems 16, state office 
systems 18, and franchise office systems 20. Lowest level control may be 
20 provided by franchise office systems 20 and/or node office systems 28. 
OMS 12 also controls the operations of various support systems 32 which 
may also be accessed by the various hierarchical control systems 30. 

In addition to top-level down control, the present invention 
also provides a system for access by every node on the system to every 
25 other node's information. The ability to provide communications and 
links between customers, accounts, and service locations across system 10 
is provided. This unique link between customers, accounts, and service 
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locations allows for access to this information system wide. 
Customer- Account-Service Location Linking 

The present invention allows for a customer to have one or 
more accounts and one or more service locations. Also, an account 
5 preferably may only be associated with one customer. Also, an account 
may have one or more service locations. Further, a service location may 
be associated with zero, one or many customers and zero, one or many 
accounts. 

This ability may be provided by establishing a record for 

10 each customer, account, and service location. In each record for a 
customer, links to a plurality of account records and service location 
records may be permitted. Additionally, for each account, a link to a 
single customer record and one or more service location records may be 
permitted. Further, for each service location, a link to one or more 

15 customers and one or more accounts may be permitted. 

In a preferred embodiment, a customer record may comprise 
the customer last name, customer first name, customer middle name, 
organization name, customer type, language, language type, customer ID 
(generated by customer support component 92), social security number (if 

20 the customer is an individual), telephone number, telephone extension, 
telephone type, address, drivers license number and state, customer PIN, 
comment information, preferences, account members name, account 
member relationship to customer, account member PIN, young children, 
old children, account numbers) (by links to account number records) and 

25 service locations (by links to service location records). 

An account record preferably comprises account number 
(generated by customer support component 92), bill method, bill cycle, 
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bill frequency, movie rating, alternative addresses, PIN, credit limit, 
account member privileges, credit card number, credit card expiration 
date, credit card type, bank identifier, bank account number, customer (by 
a link to a customer record), and service locations (by links to service 
5 location records). 

A service location record preferably comprises a status, 
serviceability date, street number, street name, city, state, zip cope and zip 
extension, account type, franchise area, management area, schedule area, 
head end ID, amplifier ID, control number, complex number, fraction, 

10 definition, direction, unit number, building number, map coordinates, 
sales route, overhead/underground, legal lot, legal description, drop 
location, outlet number, outlet location, equipment ID, AB switch, 
comment information, credit card number, customers (by links to 
customer records), and accounts (by links to account records). 

15 Customer Service Interface 

The present invention also includes an interfacing 
component which has particular utility for customer service functions. At 
each terminal on the system, a copy of or access to a graphical user 
interface component is provided. The graphical user interface enables the 

20 user to input and receive information stored or to be stored on system 10. 
Typically, users access this at a customer service processor at one of the 
hierarchical systems 30 or at OMS 12, although any terminal on system 
10 may be used, for simplicity of explanation, a customer service 
processor is described as the medium of access. 

25 Flow of a portion of the graphical user interface is depicted 

in a flow diagram shown as Fig. 6. From any non-application space 200 
at one of the customer service processors, the graphical user interface 
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component may be activated. Non-application space 200 may comprise 
any operating system for a personal computer such as operating systems 
sold under the trademark DOS or Windows by Microsoft, Inc., under the 
trademark Macintosh by Apple, Inc, or under the trademark UNIX by Bell 
5 Laboratories, Inc. The initial operation of the graphical user interface 
component is to present a log in window 202. 

Preferably, every user has a password associated with their 
log in name. Customer service processors accept as input a log in name 
and password. Upon receipt of this information, an initial determination 

10 is made to ensure that the user has been defined on the system. The 
graphical user interface component receives the input and makes an 
inquiry of OMS 12 which can cross reference a user database maintained 
at one of the database access systems 104, If the user has been defined, 
information on the user's authority is passed back to the graphical user 

15 interface component. For example, the user's authority may be corporate, 
division, state, franchise, or node. User authority determines what actions 
may be taken, as described in detail above. 

If the user authority is determined to be either corporate, 
division, or state, for example, then in one preferred embodiment, 

20 graphical user interface component transfers control to an administrative 
scenarios component 204. At the administrative scenarios component 
204, a user may perform certain administrative functions. 

At the administrative scenarios component 204, a user may 
either exit back to log in window 202 or move to a taking calls window 

25 206. Typically, a user with administrative authority will not receive 

customer service calls. However, if the user does decide to take incoming 
calls, then an option is presented by the administrative scenarios 
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component 204 to move to the taking calls window 206. 

A non administrative authority user is transferred by the 
graphical user interface component to taking calls window 206. If a user 
decides that he or she is not available for customer service calls, an option 
5 is presented in the taking calls window to block calls and control is 
transferred to a blocking calls window 208. From the blocking calls 
window, a user may exit back to log in window 202 or he or she may 
move to the administrative scenarios component 204 or taking calls 
window 206. 

10 Taking calls window 206 enables a user to receive incoming 

customer service telephone calls. Taking calls window 206 presents the 
user with an incoming icon or other selection device. By selecting the 
incoming icon, a customer service call is received. The initial function 
that is required to service a customer request is to identify either the 

1 5 customer, service location, or account about which the call is being 

placed. Therefore, upon selecting the incoming icon, control passes to a 
search window 210. 

ARU units associated with the customer service processors 
on which the graphical user interface is operating may automatically 

20 identify the customer as is known in the art. As such, entry into search 
window 210 is not necessary. If an ARU unit is not operating, or is not 
providing calling number information, entry into search window 210 is 
mandatory to identify and gather information about the customer. 

From search window 210, a user may transfer to a 

25 commercial PPV window 2 14, if the caller is a commercial customer 
calling regarding PPV information. If the caller is non-commercial and 
requests other information, a search scenarios component 212 may be 
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activated. 

Search scenarios component 212 provides the ability to 
search for a customer, service location or account in the customer 
database maintained at one or more of the database access systems. A 
5 search for a customer, service location or account may be performed in a 
preferred embodiment, searches may be performed by one of the 
following methods: 

1) customer name; 

2) customer ID; 

10 3) customer phone number (may be through an ARU, 

for example); 

4) service location address; 

5) service location equipment ID; 

6) account number; 

15 7) hotel and room; and 

8) hotel and credit card number. 

Upon a successful search, control then passes through 
taking calls window 206 to a selection window 216. Selection window 

20 216 enables the user to determine which information should be presented. 
The user may select one or more of the following: an account window, a 
members window, a service locations window and a customer window. 
Each selection indicates to the graphical user interface what information 
to request from the customer database. In a preferred embodiment, this 

25 information is requested and transferred from the customer database to the 
customer service processor making the request. 

From the selection window, then a user may cancel and 
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return to taking calls window 206 or indicate approval of his or her 
selections and control passes to an overview window 218 (depicted as a 
box in Fig. 6) which contains five windows: a banner window 220, a 
service location window 222, a bill window 224, an account window 226 
5 and a browser window 228. Overview window enables the user access to 
all or at least most of the information about a customer-service location- 
account link within one or two selections of buttons or icons on the 
overview window. Overview window thus enables a user such as a 
customer service representative to quickly and effectively answer or 
0 adjust most customer related information. An example of an overview 
window is depicted in Fig. 7 and is described in detail below. 

If a customer, service location or account is not identified 
through search window 2 1 0, control passes through selection window 2 1 6 
and banner window 220 to a customer window 230 and a check list 
5 window 232. Customer window 230 and check list window 232 may be 
presented simultaneously to a user and present the user with the ability to 
add a new customer to the customer database. 

Banner window 220 contains summary information about 
the customer. As depicted in Fig. 7, banner window 220 may comprise a 
) customer information portion 3 1 4 which may contain fields showing 
customer name, address, creation date, account type, personal 
identification number, and balance, for example. Banner window 220 
also may contain several icons including a search icon 300 (for 
transferring control to search window 210), a take call icon 302 (to accept 
a customer service call), a block icon 304 (to transfer control to blocking 
calls window 208), a logs icon 306 (to move to a logs window 234), a 
warnings icon 308 (to move to a warnings window 236), a revert icon 
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310, and a save icon 3 12 (to activate any changes). 

Logs window 234 may provide the user with a listing of all 
logs compiled. For example, each customer service request may be 
logged. Warnings window 236 may provide the user with information 

5 about warnings 

By selecting on customer information portion 3 14, the user 
may also move to a customer window. Figs. 8 and 9 depict examples of 
customer windows for both an individual customer (Fig. 8) and an 
organizational customer (Fig. 9). In customer windows, information 

1 0 about the customer may be altered. 

Service location window 222, bill window 224, and account 
window 226 may comprise a plurality of panels which enable the window 
to provide larger amounts of information in a more readable fashion. 
Each panel may provide different information and may be selected by 

15 clicking on a tab represented at the top of the panel. For example, in Fig. 
7, an address panel 238 of service location window 222 may be selected 
when a user, using an input device such as a mouse, for example, selects a 
tab 260 which is placed at the top of address panel 238. When a panel is 
selected, the contents of the panel are presented overlying the contents of 

20 other panels in the same window. 

In a preferred embodiment, service location window 222 
may comprise an address panel 238, a contents panel 240 and a legal 
panel 242. When a panel is selected, the graphical user interface system 
passes control to that panel. In a preferred embodiment, customer service 

25 representative users do not have authority to change the address of a 
service location without first going to a dispatch window 258 which 
operates with dispatch component 84 of OMS 12 to dispatch a service 
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unit to dislocate at the current address and/or hook up service at a new 
service location. 

Address panel 238 preferably comprises fields for creation 
date, street number, street fraction, street direction, street type, city, state, 
5 zip, country, county, franchise, and sales route, for example, as depicted 
in Fig. 7. Contents panel 240 preferably comprises fields for room 
number, room ID, room location, type, outlet number, cable ready, AB 
switch, splitter used, equipment function, equipment serial number, 
equipment model, and equipment brand, for example, as depicted in 

10 contents panel 240 of Fig. 10. Legal panel 242 may comprise fields for 
service date, subdivision name, geographical location/map, complex, 
building type, amp ID, catl ID, latitude, longitude, overhead, drop 
description, description, legal description, legal lot number, and right of 
entry, for example, as depicted in Fig. 1 1. 

1 5 Bill window 224 may comprise two panels: a bill payment 

panel 244 and a bill ledger panel 246 as depicted in Fig. 7. Bill payment 
panel 244 may comprise fields for a bill to location, billing name, and 
billing address, for example. From this window, control may be passed to 
an address edit window 270 if the customer wishes to change the address 

20 for billing purposes. In a preferred embodiment bill payment panel 244 
may further comprise three sub-panels which may be activated by 
selecting a node 275 on bill payment panel 244, for example. Bill ledger 
panel 246 may comprise fields to display payments, charges and other bill 
related data, for example. From either bill payment panel 244 or bill 

25 ledger panel 246, a user may view an image of bill through bill image 
window 276. Bill image window 276 provides an image which depicts 
exactly what the customer's bill will look like for a specified billing 
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cycle. 

The subpanels for bill payment panel 244 may comprise a 
statement subpanel 262 (depicted in Fig. 7), account subpanel 264 
(depicted in Fig. 12), and credit card subpanel 266 (depicted in Fig. 13), 
5 for example. Statement subpanel 262 may comprise fields for statement 
frequency, statement billing cycle, and statement due date, for example. 
Account subpanel 264 may comprise fields for a bank ID, bank account 
number, billing frequency, billing cycle and billing due date, for example. 
Credit card subpanel 266 may comprise fields for a credit card number, 

10 credit card expiration month, expiration year, billing frequency, billing 
cycle and billing due date, for example. 

Account window 226 may comprise four panels: a products 
panel 248 (depicted in Fig. 14), a members panel 250 (depicted in Fig. 7), 
an outlets panel 252 (depicted in Fig. 15), and a details panel 254 

15 (depicted in Fig. 16), for example. Products panel 248 may comprise 
fields for products, schedule date, price, and frequency of charge. 
Products panel 248 may also comprise several icons, for example, a 
disconnect icon 280, a pay-per-view icon 282 and a sell icon 284. By 
selecting disconnect icon 280 or sell icon 284, control passes to an order 

20 processing window 278 for adding or deleting products or services. By 
selecting pay-per-view icon 282, control passes to a pay-per-view window 
286 for ordering pay-per-view events. 

Members panel 250 may comprise fields for member 
names, member relations, member account privileges and pay-per-view 

25 privileges. Icons for adding and deleting members may also be provided. 
Outlets panel 252, an example of which is depicted in Fig. 15, may 
comprise fields for outlet names, outlet number, outlet products, outlet 
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price range and outlet price, for example. If a user desires to change 
outlets, pricing, etc., control transfers to order processing window 278. 
Details panel 254, an example of which is depicted in Fig. 16, may 
comprise fields for last modification, creation date, account number, 
5 account type, account product type, credit line, personal identification 
number and mailing address, for example. Should the user request that 
the mailing address be changed, control passes to address edit window 
270 for servicing that request. 

Browser window 228 comprises a depiction of the 
1 0 arrangement of bill, account, and service location for a particular 

customer. A particular account or service location which may have been 
selected is indicated as selected, for example, as service location Logan in 
Fig. 7. An icon is presented in browser window 228 to enable the user to 
enlarge browser window 228 to be presented on the entire screen in place 
15 of the overview window. 

Browser window 228 shows the context of overview 
window 218 and allows insertion, deletion, and display of various nodes 
associated with the customer. The nodes may comprise customer- 
>account->(member -> product-> service location -> room -> outlet -> 
20 equipment), where the members, products, and service locations can be 
presented in parallel. The arrows used in describing the nodes above 
represent columns in the browser, for example. By single clicking with a 
mouse, or other input device, for example, on a particular node and 
holding the mouse button down (alternatively, with a keyboard, the user 
25 may hold down the shift key while pressing the down arrow), a drop 
down menu appears showing the user the actions which may be taken for 
that particular node. To display a column to the right of the selected 
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column, Expand may be chosen from the drop down menu for the node 
which is currently selected. When expand is chosen from an account 
node, an hierarchical menu appears giving the choice of expanding on 
members, service locations, or products. When service location is 
5 chosen, another hierarchical menu is presented to enable a user to expand 
either active or inactive service locations or both. A collapse command 
may also be presented in the drop down menu which provided the oppose 
of the expand. New and delete are also options provided in the drop 
down menu. 

10 As illustrated above, the present invention provides a 

graphical user interface which provides an overview window. This 
overview window allows a user such as a customer service representative 
located at any terminal on system 10 to access all or at least most of the 
information about any customer-account-service location relationship 

15 which is stored in the customer database within one click on a tab or 

node. This provides for global information, support, and changes because 
all requests for information and changes are funneled through OMS 12. 
Thus, a distributed network with information sharing is provided and a 
unique and easy manner of accessing provides for efficient operation. 

20 While this invention has been described with reference to 

specific embodiments, it is not intended that the invention been limited 
thereto. The invention is only limited by the claims which follow. 
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WE CLAIM: 

1 . A system for managing products, services and customers 
comprising: 

an operational management system comprising an 
5 operational processing system, a database access system and at least one 
customer service processor; 

at least one hierarchical system, said operational 
management system communicating with said at least one hierarchical 
system through a network. 

10 2. The system of claim 1 wherein said network is a wide area 

network. 

3. The system of claim 1 further comprising at least one 
support system. 

4. The system of claim 1 wherein said at least one hierarchical 
15 system comprises at least one divisional office system and at least one 

node office system. 

5. The system of claim 1 wherein said at least one state office 
system and at least one node office system. 

6. The system of claim 1 wherein said at least one hierarchical 
20 system comprises at least one divisional office system, at least one state 

office system, at least one franchise system and at least one node office 
system. 

7. The system of claim 1 wherein said operational processing 
system includes a billing production component. 

25 8. The system of claim 1 wherein said operational processing 

system includes a product/rating component. 

9. The system of claim 7 wherein said billing production 
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component comprises: 

means for monitoring a current time and date; 
means for generating a file containing customer bill 
records to be processed; 
5 means for distributing the customer bill records into 

groups based upon the geographical location of the customer; 

means for dividing the groups into one or more 
subgroups, wherein each customer bill distributed into each subgroup 
shares at least one common property; 
10 means for dividing the subgroups into processing 

groups, wherein the number of customer bills records distributed into 
each processing group is predetermined and; 

processor means for processing the customer bill 
records from at least one of the processing group files. 
15 10. The system of claim 8 wherein said product/rating 

component is operative to provide a product to a plurality of customers, 
the system being accessed by a plurality of users, each user having an 
authority from authority level A = 1 to n, with n being the highest 
authority level, said product/rating component comprising: 
20 memory means for storing a plurality of product 

records; 

at least a first input means for inputting from an n- 
level authority user n-level parameters to define a product; 

at least a first processor means, operatively 
25 connected to said memory means and said at least one input means, for 
creating an n-level product record comprising the n-level parameters and 
storing the n-level product record in said memory means; 
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a plurality of second input means for inputting from 
a level 1 authority user level 1 parameters to redefine a product having an 
n-level product record, wherein the level 1 parameters are more specific 
than the n-level parameters; 
5 a plurality of second processor means, operatively 

connected to said memory means and to one of the second input means, 
for creating a level 1 product record comprising the n-level parameters 
and the level 1 parameters and storing the level 1 product record in the 
memory means; and 
1 0 a plurality of third processor means, operatively 

connected to the memory means, for accessing the memory means to 
receive one of the level 1 product records and providing a product to a 
plurality of customers according to the parameters of that level 1 product 
record. 

15 11 The system of claim 10 wherein the n-level parameters 

comprise maximum price and minimum price and wherein the level 1 
parameters comprise an offer price and wherein the offer price must be 
less than or equal to the maximum price and greater than or equal to the 
minimum price. 

20 12. The system of claim 1 wherein said database access system 

comprises: 

a plurality of data servers; and 

data directory server means in communication with said 
operational processing system and each of said data servers, said data 
25 directory server means receiving database transactions from said 
transaction generator means and selecting at least one data server for 
processing each said database transaction. 
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13. The system of claim 12 further comprising at least one 
cross-reference server, said cross-reference servers providing data 
location information to said data directory servers. 

14. The system of claim 12 wherein said plurality of data 

5 servers operate in parallel to process a plurality of database transactions 
concurrently. 

15. The system of claim 1 wherein said system supports a 
plurality of customers each associated with one or more accounts and 
with one or more service locations and wherein: 

10 said database access system stores customer records, account 

records and service location records for associating each customer record 
with at least one account record and at least one service location record, 
for associating each account record with at least one customer record and 
at least one service location record, and for associating each service 

15 location record with at least one customer record and at least one account 
record; 

said at least one customer service processor accessing said 
database access system for information contained in any customer record, 
any service location record, and any account record stored in said 
20 database access system, said customer service processor further 
comprising: 

input means for receiving a customer service request; 

access means for retrieving at least one customer record, at 
least one account record, and at least one service location record in 
25 response to the customer service request; and 

means for displaying a graphical user interface comprising a 
banner window, an account window, and a service location window; 
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wherein the banner window comprises fields for customer 
related information, the account window comprises fields for account 
related information and the service location window comprises fields for 
service location related information. 
5 16. The system of claim 15 wherein the customer service 

requests comprise either a customer request, an account request, a service 
location request, or a bill request and wherein each customer record is 
associated with one or more account records and one or more service 
location records, each account record is associated with one or more 
10 customer records and one or more service location records and each 
service location record is associated with one or more customer records 
and one or more account records. 

17. A subscriber management system comprising: 

an operational management system, said operational 
15 management system operative for controlling the delivery and billing of 
products and services; 

a plurality of node office systems, said node office systems 
communicating with said operational management system over a network, 
each of said node office systems being associated with a plurality of 
20 customers, service locations and accounts; 

a distributed database system including a plurality of data 
servers and at least one data directory server, said distributed database 
system being accessible for reading and writing data by said operational 
management system and by each of said node office systems. 
25 18 The system of claim 17 wherein each of said node office 

systems comprises a cable television product delivery device, said product 
delivery device delivering a cable television product to a service location 
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associated with said node office system. 

19. The system of claim 17 wherein said node office system 
comprises at least one node customer service processor, said node 
customer service processor accessing customer, account and service 

5 location data associated with said node office system. 

20. The system of claim 17 wherein said operational 
management system comprises a product/rating component, a bill 
production component and a customer service component. 
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